The other hard part for Autodiscover is managing the
required SSL certificates. After working with a number of Exchange 2007
deployments, we began to realize that the biggest difficulty with
Autodiscover certificates was inevitably the need to use a SAN
certificate. While other scenarios are possible (such as creating a
separate Autodiscover website on a separate IP address and using a
second single-name certificate) as outlined in the Exchange 2007
Autodiscover white paper, these options ended up being far more
complicated to run.
So what's so hard about SAN
certificates? We think that for most people, they don't understand what
certificates really are or how they work. Certificates and PKIs are
black magic—stark naked voodoo—mainly because they've traditionally been
complicated to deploy and play with. Getting even an internal PKI like
the Windows Server 2008 Active Directory Certificates Services in place
and running can be hard to manage unless you already know what to do and
what the results should look like. Add to that the difficulty of
managing certificates with the built-in Windows tools, and most Exchange
administrators we know want to stay far away from TLS and SSL.
Although Exchange 2010 follows
the lead of Exchange 2007 and installs self-signed certificates on each
new server, these certificates are not meant to take you into
production for all scenarios. You won't be able to use them to secure
client access for any of your users who are connecting remotely, even
though Outlook will bypass its certificate validation checks when it
detects an Exchange self-signed certificate as long as it is connecting
from within the domain. Internal Outlook clients can
use the self-signed certificates, but Outlook does not ignore
improperly matched names or expired certificates. Internal Outlook
clients will just ignore the fact that the certificate is from an
untrusted certificate authority.
External or web-based clients
won't accept a self-signed certificate without you manually importing
the certificate—which is a huge administrative burden for mobile
clients. For externally facing deployments, you either need to have a
well-managed PKI deployment or use a third-party commercial certificate
authority. Make sure that you use one whose root and intermediate CA
certificates are well supported by the operating systems and devices
that will be connecting to your network.
1. The X.509 Certificate Standard
The digital certificates that Exchange and other SSL/TLS-aware systems
use are defined by the X.509 v3 certificate standard. This standard is
documented in RFC 2459. The X.509 certificates were originally developed
as part of the X.500 family of standards from the OSI, but proved to be
useful enough that they were adopted by other standards organizations.
The X.509 certificates are based on the concept of private key cryptography.
In this system, you have an algorithm that generates a pair of
cryptographic keys for each entity that will be exchanging encrypted
message traffic: a private key that only that entity knows, and a corresponding public key
that can be freely transmitted. As long as the private keys are kept
safe, the system can be used to not only securely encrypt messages but
also to prove that messages were sent from the claimed sender. The
exclusivity of the private key provides authentication as well as
security.
If Jim and Devin want to exchange encrypted messages using a private key system, here's how it works:
Both
Jim and Devin ensure that they have secure private keys. They have
exchanged their corresponding public keys—maybe through email, by
publishing them on their websites, or even through a mutual friend.
Jim,
when sending a message to Devin, will use Jim's public key and Devin's
public key to encrypt the message. This ensures that only Devin will be
able to decrypt the message.
Devin
receives the encrypted messages and uses his private key and Jim's
public key to decrypt the message. This ensures that the message
actually came from Jim.
When
Devin receives the message, he uses his own private key to decrypt the
message. If Devin wants to send a message to Jim in return, he simply
reverses the process: he uses his public key and Jim's public key to
encrypt, and Jim uses his private key. If Devin later needs to open the
message in his Sent Items folder, he would use his private key to
decrypt.
Digital certificates help
streamline this process and expand it for more uses than just message
encryption by providing a convenient wrapper format for the public keys
plus some associated metadata. For our purposes, though, we're concerned
about using certificates for server authentication and establishing the
symmetric shared session key for the TLS session.
In Windows, you can
view digital certificates, examine their properties, and validate the
certificate chain through the MMC. Although Windows doesn't include a
preconfigured Certificate console, it does include a Certificate
snap-in. Open a generic MMC and add the Certificate snap-in, configured
for the local machine as shown in Figure 1. You can now view and manage the server certificates that will be used by Exchange.
While you can view the
properties of a certificate using the certificates console, all
certificates that are used by Exchange (for HTTPS, SMTP, IMAP, or POP)
should be managed using either the Exchange Management Console or the
Exchange Management Shell.
Let's take a look at the typical properties of an X.509v3 digital certificate as provisioned for Exchange, shown in Figure 2 :
Subject Name
This property provides
the identity of the entity the certificate applies to. This can be in
X.500 format, which looks like LDAP, or in DNS format if intended for a
server.
Subject Alternate Name
This is an
optional property that lists one or more additional identities that will
match the certificate. If the hostname in the URL that the client
attempts to connect to doesn't match the subject name or subject
alternate name properties, the certificate will not validate. Without
this property, a certificate can only match a single hostname.
Common Name
Also known as the
friendly name, this property provides a useful text tag for handling and
managing the certificate once you have a collection of them.
Issuer
This property lists the
identity of the issuing certificate authority (CA). This can be a root
CA or an intermediate CA. Combined with the digital signature from the
CA's own digital signature, this property allows establishment of the
certificate chain of trust back to the root CA. What distinguishes a
root CA? The fact that this property (plus signature) is self-signed.
Serial Number
This property allows
the certificate to be easily published on a certificate revocation list
(CRL) by the certificate authority if the certificate has been expired.
The location of the CRL is usually included on the issuer's certificate.
Many systems, including Outlook, attempt to check the CRL to verify the
certificate has not expired.
Thumbprint
This property (and
the corresponding thumbprint algorithm) is a cryptographic hash of the
certificate information. This thumbprint is commonly used by Exchange as
an easy identifier for certificates.
Valid From and Valid To
These properties define the effective length of the certificate. They are evaluated as part of the certificate validation.
Public Key
This property
contains the entity's associated cryptographic public key. The
corresponding private key is never associated with the certificate.
In Figure 3, we can see the certificate trust chain and verify that we have the proper CA certificates installed.
